Si bien el último año o dos han visto una serie de propuestas de extensiones de propuestas de convenio para Bitcoin, siempre ha existido una sospecha entre los expertos de que los convenios pueden ser posibles sin ninguna extensión. La evidencia de esto se ha presentado de dos formas: un repertorio en expansión de cálculos previamente considerados imposibles en (culminando en el proyecto BitVM para implementar cada opcode de RISC-V), y una serie de "casi-aciertos" mediante los cuales los desarrolladores de Bitcoin han encontrado formas en las que los convenios habrían sido posibles, de no ser por algún capricho histórico oscuro del .

Ethan Heilman, Avihu Levy, Victor Kobolov y yo hemos desarrollado un esquema que demuestra que esta sospecha estaba bien fundamentada. Nuestro esquema, Collider*, permite pactos en Bitcoin hoy en día, bajo suposiciones criptográficas bastante razonables y a un costo probable de alrededor de 50 millones de dólares por transacción (más algunos gastos de investigación y desarrollo de hardware).*

A pesar de los costos extravagantes para usar Collider, configurarlo es muy barato, y hacerlo (junto con un mecanismo de gasto ordinario, usando Taproot para separar los dos) solo podría salvar tus monedas en caso de que aparezca una computadora cuántica de la nada y vuele por los aires el .

Sin duda, muchos lectores, después de leer estas afirmaciones, están levantando una ceja hacia el cielo. Para cuando termines de leer este artículo, la otra también estará igual de alta.

Convenios

El contexto de esta discusión, para aquellos que no estén familiarizados, es que Bitcoin tiene un lenguaje de programación incorporado, llamado Bitcoin, que se utiliza para autorizar el gasto de monedas. En sus primeros días, Bitcoin contenía un conjunto completo de códigos de operación aritmética que se podían utilizar para implementar cálculos arbitrarios. Pero en el verano de 2010, Satoshi desactivó muchos de ellos con el fin de corregir una serie de errores graves. (El objetivo del Gran Proyecto de Restauración es volver a la versión previa a 2010 de Bitcoin; OP_CAT es una propuesta menos ambiciosa en la misma dirección). La idea de los convenios, es decir, las transacciones que utilizan códigos de operación para controlar la cantidad y el destino de sus monedas, no apareció hasta varios años después, y la realización de que estos códigos de operación habrían sido suficientes para implementar los convenios no llegó hasta mucho más tarde. En ese momento, la comunidad era demasiado grande y cautelosa como para simplemente "volver a habilitar" los antiguos códigos de operación de la misma manera en que se habían desactivado.

Los convenios son construcciones hipotéticas que permitirían a los usuarios controlar no solo las condiciones en las que se gastan las monedas, sino también su destino. Esta es la base de muchas construcciones potenciales en Bitcoin, desde bóvedas y billeteras con límite de velocidad, hasta nuevos mecanismos de mercado de tarifas como las piscinas de pago, hasta construcciones menos deseables como las finanzas distribuidas y el MEV. Se han gastado millones de palabras debatiendo la deseabilidad de los convenios y lo que harían a la naturaleza de Bitcoin.

En este artículo evitaré este debate y simplemente argumentaré que los convenios ya son posibles en Bitcoin; que eventualmente descubriremos cómo son posibles (sin un gran costo computacional o supuestos criptográficos cuestionables); y que nuestro debate sobre nuevas extensiones a Bitcoin no debería ser planteado como si los cambios individuales fueran la línea divisoria entre un futuro sin convenios o un futuro con convenios para Bitcoin.

Historia

A lo largo de los años, se desarrolló una tradición de encontrar formas creativas de hacer cosas no triviales incluso con un límite. La Lightning Network fue una instancia de esto, al igual que ideas menos conocidas como pagos probabilísticos o recompensas por colisión para funciones hash. Casos de borde oscuros, como el error SIGHASH_SINGLE o el uso de la recuperación de clave pública para obtener un "hash de transacción" dentro del intérprete, fueron notados y explorados, pero nadie encontró una forma de hacerlos útiles. Mientras tanto, Bitcoin mismo evolucionó para ser más definido, cerrando muchas de estas puertas. Por ejemplo, Segwit eliminó el error SIGHASH_SINGLE y separó explícitamente los datos del programa de los datos del testigo; Taproot se deshizo de la recuperación de clave pública, que proporcionaba flexibilidad a costa de socavar potencialmente la seguridad para firmas de adaptadores o multisignaturas.

A pesar de estos cambios, los ataques continuaron, al igual que la creencia entre los más acérrimos de que de alguna manera se podría encontrar un caso especial que permitiera el soporte de convenios en Bitcoin. A principios de la década de 2020, dos desarrollos en particular causaron sensación. Uno fue mi propio descubrimiento de que los convenios basados en firmas no habían muerto con la recuperación de claves públicas, y que en particular, si tuviéramos al menos un código de operación deshabilitado, OP_CAT, esto sería suficiente para una construcción de convenio bastante eficiente. El otro fue BitVM, una forma novedosa de realizar cálculos grandes en varias transacciones, lo que inspiró una gran cantidad de investigaciones sobre cálculos básicos dentro de transacciones individuales.

Estos dos desarrollos inspiraron mucha actividad y emoción en torno a los pactos, pero también cristalizaron nuestro pensamiento sobre las limitaciones fundamentales de . En particular, parecía que los pactos podrían ser imposibles sin nuevos opcodes, ya que los datos de transacción solo se alimentaban en a través de firmas de 64 bytes y claves públicas de 32 bytes, mientras que los opcodes que soportaban BitVM solo podían trabajar con objetos de 4 bytes. Esta división se denominó "Small " y "Big ", y encontrar un puente entre los dos se volvió sinónimo (al menos en mi mente) de encontrar una construcción de pacto.

Encriptación funcional y tuberías (PIPEs)

También se observó que, con un poco de matemáticas lunares, podría ser posible realizar convenios enteramente dentro de las propias firmas, sin salir nunca de Big. Esta idea fue articulada por Jeremy Rubin en su artículo FE'd Up Covenants, que describía cómo implementar convenios utilizando una primitiva criptográfica hipotética llamada encriptación funcional. Meses más tarde, Misha Komorov propuso un esquema específico llamado PIPEs que parece hacer realidad esta idea hipotética.

Este es un desarrollo emocionante, aunque sufre de dos limitaciones importantes: una es que implica una configuración confiable, lo que significa que la persona que crea el pacto puede pasar por alto sus reglas. (Esto está bien para algo como bóvedas, en las que el propietario de las monedas puede ser confiable para no socavar su propia seguridad; pero no está bien para algo como pool de pagos donde las monedas en el pacto no son propiedad del creador del pacto.) La otra limitación es que implica criptografía de vanguardia con propiedades de seguridad poco claras. Esta última limitación desaparecerá con más investigación, pero la configuración confiable es inherente al enfoque funcional-01928374656574839201.

Collider

Esta visión general nos lleva a la situación actual: nos gustaría encontrar una forma de implementar covenants utilizando la forma existente de Bitcoin, y creemos que la forma de hacerlo es encontrar algún tipo de puente entre el "Grande" de las firmas de transacción y el "Pequeño" de los cálculos arbitrarios. Parece que no hay opcodes que puedan formar directamente este puente (ver Apéndice A en nuestro artículo para una clasificación de todos los opcodes en términos de su tamaño de entrada y salida). Un puente, si existiera, sería algún tipo de construcción que tomara un objeto grande y demostrara que es exactamente igual a la concatenación de varios objetos pequeños. Parece, basado en nuestra clasificación de opcodes, que esto es imposible.

Sin embargo, en criptografía a menudo debilitamos nociones como "exactamente iguales", en lugar de usar nociones como "computacionalmente indistinguible" o "estadísticamente indistinguible", y así evitamos resultados imposibles. Tal vez, utilizando los constructos criptográficos incorporados de Big -- hashes y firmas de curvas elípticas -- y reflejándolos mediante construcciones de BitVM en Small, podríamos encontrar una manera de mostrar que un objeto grande era "computacionalmente indistinguible" de una serie de objetos pequeños? Con Collider, esto es exactamente lo que hicimos.

¿Qué significa esto? Bueno, recuerda la colisión de la función hash recompensa que mencionamos anteriormente. La premisa de esta recompensa es que cualquiera que pueda "colisionar" una función hash, proporcionando dos entradas que tengan la misma salida de hash, puede demostrar en Big que lo hizo, y así reclamar la recompensa. Dado que el espacio de entrada de una función hash es mucho más grande (todos los bytes de hasta 520 bytes de tamaño) que el espacio de salida (bytes de exactamente 32 bytes de tamaño), matemáticamente hablando debe haber muchas colisiones de este tipo. Y sin embargo, con la excepción de SHA1, nadie ha encontrado una forma más rápida de encontrar estas colisiones que simplemente llamando a la función hash una y otra vez y viendo si el resultado coincide con el de un intento anterior.

Esto significa que, en promedio, para una función hash de 160 bits como SHA1 o RIPEMD160, un usuario necesitará hacer al menos 2^80 trabajos, o un millón de millones de millones de iteraciones, para encontrar una colisión. (En el caso de SHA1, hay un atajo si el usuario puede usar entradas de una forma particular; pero nuestra construcción prohíbe esto, por lo que para nuestros propósitos podemos ignorar este ataque.) Esto supone que el usuario tiene una cantidad efectivamente infinita de memoria para trabajar; con suposiciones más realistas, necesitamos agregar otro factor de cien o algo así.

Si imaginamos que SHA1 y RIPEMD160 se pueden calcular tan eficientemente como los ASIC de Bitcoin calculan SHA256, entonces el costo de dicha computación sería aproximadamente el mismo que el de 200 bloques, o alrededor de 625 BTC (46 millones de dólares). Esto es mucho dinero, pero muchas personas tienen acceso a una suma así, por lo que esto es posible.

Para encontrar una colisión triple, o tres entradas que se evalúen como lo mismo, tomaría alrededor de 2^110 trabajos, incluso con suposiciones muy generosas sobre el acceso a la memoria. Para obtener este número, necesitamos agregar otro factor de 16 millones a nuestro costo, lo que eleva nuestro total a más de 700 billones de dólares. Esto también es mucho dinero, y al que nadie tiene acceso hoy en día.

La esencia de nuestra construcción es la siguiente: para demostrar que una serie de pequeños objetos es equivalente a un solo objeto grande, primero encontramos una colisión de hash entre nuestro objeto objetivo (que asumimos que puede ser realeatorizado de alguna manera, o de lo contrario estaríamos haciendo una "búsqueda de segunda aparición" en lugar de una búsqueda de colisión, que sería mucho más difícil) y un "objeto de prueba de equivalencia". Estos objetos de prueba de equivalencia se construyen de tal manera que pueden ser fácilmente manipulados tanto en Big como en Small.

Nuestra construcción luego verifica, en Bitcoin, tanto que nuestro objeto grande colisiona con nuestro probador de equivalencia (utilizando exactamente los mismos métodos que en la recompensa de colisión de hash) como que nuestra serie de objetos pequeños colisiona con el probador de equivalencia (utilizando construcciones complejas parcialmente tomadas del proyecto BitVM y descritas en detalle en el documento). Si estas verificaciones pasan, entonces o nuestros objetos pequeños y grandes eran iguales, o el usuario encontró una triple colisión: dos objetos diferentes que colisionan con el probador. Según nuestro argumento anterior, esto es imposible.

Conclusion

Tender puentes entre lo pequeño y lo grande es la parte más difícil de la construcción de nuestro pacto. Para pasar de este puente a un pacto real, hay algunos pasos más, que son comparativamente fáciles. En particular, un pacto primero le pide al usuario que firme la transacción usando la "clave generadora" especial, que podemos verificar usando el código de operación OP_CHECKSIG. Usando el puente, dividimos esta firma en trozos de 4 bytes. A continuación, verificamos que su nonce también era igual a la clave del generador, lo cual es fácil de hacer una vez que se ha roto la firma. Por último, utilizamos técnicas del truco de Schnorr para extraer los datos de la transacción de la firma, que luego se pueden restringir de la forma que quiera el pacto.

Hay algunas otras cosas que podemos hacer: el Apéndice C describe una construcción de firma de anillo que permitiría que las monedas fueran firmadas por una de un conjunto de claves públicas, sin revelar cuál se usó. En este caso, usamos el puente para dividir la clave pública, en lugar de la firma. Hacerlo nos brinda una mejora significativa en eficiencia en relación con la construcción del pacto, por razones técnicas relacionadas con Taproot y detalladas en el documento.

Una aplicación final a la que quiero llamar la atención, discutida brevemente en la Sección 7.2 del documento, es que podemos usar nuestra construcción de convenio para extraer el hash de transacción de una firma Schnorr, y luego simplemente volver a firmar el hash usando una firma Lamport.

¿Por qué haríamos esto? Como se argumenta en el enlace anterior, firmar con Lamport de esta manera hace que sea una firma cuántica segura en los datos de la transacción; si esta construcción fuera la única forma de firmar para algunas monedas, estarían protegidas de robo por una computadora cuántica.

Por supuesto, dado que nuestra construcción requiere decenas de millones de dólares para ser utilizada, nadie haría de esta construcción la única forma de firmar sus monedas. Pero nada impide que alguien agregue esta construcción a sus monedas, además de sus métodos de gasto existentes no seguros cuánticamente.

Entonces, si nos despertáramos mañana y descubriéramos que existen computadoras cuánticas baratas capaces de romper las firmas de Bitcoin, podríamos proponer un soft-fork de emergencia que deshabilitara todas las firmas de curva elíptica, incluyendo tanto los gastos clave de Taproot como el opcode OP_CHECKSIG. Esto efectivamente congelaría las monedas de todos; pero si la alternativa fuera que las monedas de todos fueran libremente robables, tal vez no haría ninguna diferencia. Si este soft-fork de deshabilitación de firmas permitiera el opcode OP_CHECKSIG cuando se llama con la clave del generador (tales firmas de todas formas no proporcionan seguridad, y solo son útiles como un bloque de construcción para construcciones complejas como la nuestra), entonces los usuarios de nuestra construcción de firma de Lamport podrían continuar gastando sus monedas libremente, sin temor a la incautación o robo.

Por supuesto, necesitarían gastar decenas de millones de dólares para hacerlo, ¡pero esto es mucho mejor que "imposible"! ¡Y esperamos y esperamos ver que este costo 01928374656574839201 dramáticamente, a medida que las personas construyen sobre nuestra investigación.

Este es un artículo invitado de Andrew Poelstra. Las opiniones expresadas son completamente suyas y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.